home *** CD-ROM | disk | FTP | other *** search
/ kermit.columbia.edu / kermit.columbia.edu.tar / kermit.columbia.edu / newsgroups / misc.19980901-19981211 / 000187_news@newsmaster….columbia.edu _Thu Oct 22 19:36:23 1998.msg < prev    next >
Internet Message Format  |  1998-12-10  |  6KB
  1. Return-Path: <news@newsmaster.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id TAA09019
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Thu, 22 Oct 1998 19:36:22 -0400 (EDT)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id TAA27265
  7.     for kermit.misc@watsun; Thu, 22 Oct 1998 19:36:22 -0400 (EDT)
  8. Path: news.columbia.edu!watsun.cc.columbia.edu!jaltman
  9. From: jaltman@watsun.cc.columbia.edu (Jeffrey Altman)
  10. Newsgroups: comp.protocols.kermit.misc
  11. Subject: Re: Stop automatic resetting of terminal emulation?
  12. Date: 22 Oct 1998 23:36:20 GMT
  13. Organization: Columbia University
  14. Lines: 98
  15. Message-ID: <70ofhk$e9d$1@apakabar.cc.columbia.edu>
  16. References: <Pine.WNT.4.05.9810220906420.169-100000@neko.dental.washington.edu> <zr359kB7TU8S@cc.usu.edu>
  17. NNTP-Posting-Host: watsun.cc.columbia.edu
  18. Xref: news.columbia.edu comp.protocols.kermit.misc:9383
  19.  
  20. In article <zr359kB7TU8S@cc.usu.edu>, Joe Doupnik <jrd@cc.usu.edu> wrote:
  21. :     Curious that you should bring up the topic because we had gone
  22. : over it recently in the project. Let me indicate the two views on the matter.
  23. :     First is the IETF view. It says when the remote host asks repeatedly
  24. : for a terminal type the client is supposed to offer new kinds in each
  25. : response, as a negotiation process. Thus if a remote host does not understand
  26. : or accept one kind it asks again and the two sides run down their lists.
  27. : Spelling counts for everything here, and no two machines seem to agree
  28. : on spelling of terminal names. The RFCs do this haggle stuff.
  29. :     The second is my view, which is the negotiation is stupid in the
  30. : extreme. When the client responds with a terminal type that's it, there
  31. : isn't more to the game. The remote host accepts or copes or rejects. The
  32. : reason haggling is so stupid is there is a great deal more concerning
  33. : terminal emulation than just the name/kind, and changing the name/kind
  34. : upsets all other items associated with the session. Keyboard definitions,
  35. : expectations by software at either end, and so on are most often tailored
  36. : for specific terminal kinds, and here the IETF says it's fine to negotiate
  37. : away that information without a word to the user. Amazing.
  38. :     The fix, if we may use that term, is to force the terminal name
  39. : in the SET TCP TERM command so only one kind is permitted to be offered,
  40. : period.
  41. :     Joe D.
  42.  
  43. Joe:
  44.  
  45. This case is not the same as the one that you and I talked about privately.
  46. In your case, the terminal type name "VT320" is not recognized by the host,
  47. a VMS system, but after the login occurs a terminal type query is sent
  48. by the host which then recognizes the terminal type as a VT320.  This lack 
  49. of host recognition of the Telnet Terminal Type negotiation is indeed 
  50. caused by a failure of the host to have the same name for the terminal
  51. as the emulator, but because it has an alternate identification method
  52. things still work.
  53.  
  54. Now lets take the case above.  Kermit reports the terminal type name
  55. as "SCOANSI" to the host, an SCO OpenServer Unix system.  "SCOANSI" is
  56. not recognized as a valid name in the termcap and terminfo databases
  57. an so rejects it and asks for another name.  If Kermit does not respond
  58. with a new name and instead continues sending "SCOANSI" the result is
  59. that the TERM environment variable is set to "SCOANSI" and all of the 
  60. applications which are dependent on termcap and terminfo entries fail 
  61. with something like:
  62.  
  63.   $ emacs
  64.   emacs: Terminal type scoansi is not defined.
  65.   If that is not the actual type of terminal you have,
  66.   use the Bourne shell command `TERM=... export TERM' (C-shell:
  67.   `setenv TERM ...') to specify the correct type.  It may be necessary
  68.   to do `unset TERMCAP' (C-shell: `unsetenv TERMCAP') as well.
  69.   $
  70.  
  71. This happens because unlike VMS, Unix does not attempt to perform 
  72. a VT terminal id query after the login procedure succeeds when the
  73. terminal type in unknown.
  74.  
  75. SCO has corrected this problem is their current releases by adding
  76. "scoansi" as an alias for "ansi" in the terminfo database.  (They
  77. still forgot to put one there in the termcap database.)
  78.  
  79. Kermit's attempt to negotiate a terminal type that SCO recognizes is the 
  80. best method to ensure that the applications started by the user will
  81. in fact work.  Even if it means that they won't be running in the
  82. optimal environment.
  83.  
  84. The problem with the name "ANSI" as used by SCO is that there is no
  85. such thing as an ANSI terminal.  The ANSI X3.64-1979 standard (since
  86. withdrawn and replaced by ISO 6429) is just a framework upon which
  87. manufacturers could define their terminal command sets.  It did not
  88. specify a list of required functions, nor keyboard commands, nor
  89. prevent multiple but incompatible implementations of the same function.
  90. The result are implementations based on X3.64-1979 which are rather
  91. non-interoperable.  SCO should never have called its console terminal
  92. "ANSI", just as IBM should never have called its console driver 
  93. "ANSI.SYS" which was then superceded by "NANSI.SYS"....
  94.  
  95. Since the SCO console is not the same as ANSI.SYS and not the same
  96. as BeOS console or Linux console or Unixware console or QNX ANSI 
  97. console it should not be called "ANSI".  Hence, the name "SCOANSI"
  98. in Kermit in order to distiguish it from the previous "ANSI" terminal
  99. type that Kermit supported which is based on "ANSI.SYS".
  100.  
  101. Kermit 95 1.1.18 will work around all of these problems.  Not by
  102. removing the negotiation of terminal types as declared by the IETF
  103. but by enhancing its support of it by including terminal type aliases.
  104. As it turns out VMS uses the name "DEC-VT300" instead of "VT320" to
  105. describe the VT320 terminal type.  SCO already had aliases for 
  106. "ANSI" including "ANSI-850" and "ANSI-8859".  So now when "SCOANSI" is 
  107. not recognized K95 will try the other two before switching to a
  108. different terminal emulation.
  109.  
  110. Leaving the terminal type in a mode that is not recognized by the
  111. host does not serve anyone's best interest.
  112.  
  113.  
  114.     Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
  115.                  The Kermit Project * Columbia University
  116.               612 West 115th St #716 * New York, NY * 10025
  117.   http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org